Bind Kibana server to localhost #8013

thomasneirynck · 2016-08-17T19:20:47Z

thomasneirynck · 2016-08-17T21:51:10Z

~~This needs to be tested with X-Pack and reporting module~~

^ Reads from same server.host config as Kibana itself (https://github.com/elastic/x-plugins/blob/master/kibana/plugins/reporting/server/lib/get_object_queue.js#L12)

jbudz · 2016-08-23T16:25:21Z

config/kibana.yml

-# This setting specifies the IP address of the back end server.
-# server.host: "0.0.0.0"
+# Specifies the host name to which the Kibana server will bind.
+# The default is 'localhost'. With this setting, the Kibana-server will reject any incoming requests from remote users.


localhost isn't necessarily 127.0.0.1/rejecting remote requests, thoughts on something like "The default is localhost, which usually means other machines won't be able to connect"?

jbudz · 2016-08-23T16:27:21Z

one note above, otherwise clicked around with a full x-pack install and looking good.

thomasneirynck · 2016-08-23T17:50:23Z

@jbudz thanks! I improved the doc. I appreciate you testing with X-pack too.

@Bargs any thoughts? thanks!

Bargs · 2016-08-23T21:19:27Z

config/kibana.yml

+# The default is 'localhost', which usually means remote machines will not be able to connect.
+# To allow connections from remote users, set this parameter to IP or the DNS-name of the machine that is running Kibana.
+# For example: if remote users need to connect to Kibana via http://foobar:5601, set this parameter to 'foobar'.
+# server.host: "localhost"


How does Kibana determine what ip to bind to if a DNS resolved hostname is provided here? Aren't we conflating the server name with the network interface Kibana should bind to?

I wouldn't say so. It's the destination of the public API endpoint, the name the end-user will use to connect. The actual resolution of that is not all that relevant. I can setup resolution for 'foobar' in my host-file and point it to the loopback interface. Or foobar resolution could happen on the network. Either way, in both cases Kibana needs to just bind to foobar. Similarly for an IP, for Kibana it does not matter which interface is mapped to which address, as long as the address matches that of the incoming request.

We probably want to discourage mapping to IPs too. If we map Kibana to the IP assigned to the public network interface, but people connect with a DNS-name that resolves to that host, the app-server (hapiin this case) will ignore it.

Perhaps there is intricacies in a VM setup that I am not aware of though.

We should simplify the doc though, to reduce ambiguity. Something like (?)
Specifies the public hostname or IP address of the server. The default islocalhostwhich means remote machines will not be able to connect. To allow connections from remote users, set this parameter to the public host name. ...

I agree, server.host should basically be the "server name". However, I don't think the Kibana server should be doing DNS lookups to figure out what local network adapter to listen on. What if the Kibana machine doesn't have access to those name servers? What if there's a load balancer involved, and the public IP for foobar.com is different than the local IP Kibana should be listening on? We probably need a separate config value called listen or something that allows users to specify the address to listen on independently of the host name.

I'd hesitate for that.

Right now, we're borrowing the semantics and implementation straight from hapi. If we uncouple "public name"(=host) and "IP assigned to network interface"(=listen), we'll have to implement this ourselves.

Has this been a problem in the past?

Let me take a step back here. What led me down this path is this addition to the config documentation:

# To allow connections from remote users, set this parameter to IP or the DNS-name of the machine that is running Kibana. # For example: if remote users need to connect to Kibana via http://foobar:5601, set this parameter to 'foobar'.

I might need to investigate more, but I don't think that doc is correct. As far as I can tell so far, server.host does not need to be set to the publicly accessible domain name. It just needs to be set to the publicly accessible IP address of the local machine.

To see this in action:

Add an entry to /etc/hosts (or your OS's equivalent) pointing the hostname foobar to 127.0.0.1. Now start up Kibana with ./bin/kibana --host=127.0.0.1. Go to foobar:5601 in your browser. Everything works. No need to set server.host to foobar.

If you agree with that conclusion, I'd be ok with this change as long as the comment about DNS and foobar is removed.

that example works in the local case, but connections won't work from remote hosts.

You can use IP (the public IP) for this setting, it's just not a setting I would personally encourage because IP assignment is too low level to bother with IMO.

But perhaps we shouldn't be leading the witness in the doc. I'll just remove the "foobar" example. Or replace it with 0.0.0.0, and then we use the "special" case that just binds to anything.

that example works in the local case, but connections won't work from remote hosts.

Sure, if I want to expose Kibana the world, I would enter a publicly accessible IP. In that case my domain name would also get resolved by a DNS server, not /etc/hosts.

You can use IP (the public IP) for this setting, it's just not a setting I would personally encourage because IP assignment is too low level to bother with IMO.

I disagree, that's exactly the right level to think at. Kibana is deployed on a machine, and Kibana must listen on some address that machine has. This setting has nothing to do with the network external to the machine Kibana is running on (as far as I can tell), it's all about what local address Kibana should listen on. I think what you're really advocating for are some useful aliases, like elasticsearch provides. I'd totally support that.

Bargs · 2016-08-24T19:45:13Z

config/kibana.yml

+# Specifies the public host name to which the Kibana server will bind.
+# The default is 'localhost', which usually means remote machines will not be able to connect.
+# To allow connections from remote users, set this parameter to IP or the DNS-name of the machine that is running Kibana.
+# server.host: "localhost"


You're going to hate me, but I'm still not totally happy with this description. Can we say

# Specifies the address to which the Kibana server will bind. IP addresses and host names are both valid values. # The default is 'localhost', which usually means remote machines will not be able to connect. # To allow connections from remote users, set this parameter to a non-loopback address.

I think this is more accurate and it borrows from the terminology the ES docs use (referring to loopback address) so it'll look familiar across products in the stack. Sorry I'm being super nitpicky, I just think it's important to document these options so their purpose is crystal clear.

Bargs · 2016-08-24T20:11:56Z

LGTM

This is a breaking change. The default behaviour will now be that connections from remote users will be rejected.

thomasneirynck · 2016-08-25T16:43:01Z

rebased with master to get ingest test fix changes.

* Timelion is now part of master, not need to install it anymore * Default host is now localhost, 0.0.0.0 for dev needs config file: elastic/kibana#8013

Bind Kibana server to localhost. This is a breaking change. Now, Kibana will not be accessible to remote users by default. To enable this, the server.host parameter needs to be configured. Former-commit-id: f49bf02

`v95.10.1`⏩`v95.11.0` > [!note] > The bulk of this release is **EuiDataGrid**. The component has been fully converted to Emotion, and several UX changes have been made to data cell actions. We recommend QA testing any data grid(s) that have custom styles applied to them. _[Questions? Please see our Kibana upgrade FAQ.](https://github.com/elastic/eui/blob/main/wiki/eui-team-processes/upgrading-kibana.md#faq-for-kibana-teams)_ --- ## [`v95.11.0`](https://github.com/elastic/eui/releases/v95.11.0) - Updated `EuiText`, `EuiTextColor`, and `EuiTextAlign` with a new `component` prop that allows changing the default rendered `<div>` wrapper to a `<span>` or `<p>` tag. ([#7993](elastic/eui#7993)) - Updated `EuiDataGrid`'s cell actions to always consistently be left-aligned, regardless of text content alignment ([#8011](elastic/eui#8011)) - Increased `EuiDataGrid`'s cell actions hover zone to reduce UX friction when mousing over from the grid cell to its actions ([#8011](elastic/eui#8011)) **Bug fixes** - Fixed `EuiPopover` to correctly inherit from `EuiProvider`'s `componentDefaults.EuiPortal.insert` ([#8003](elastic/eui#8003)) - Fixed push `EuiFlyoutResizable`s to not potentially block scrollbars on outside content ([#8010](elastic/eui#8010)) - Fixed an `EuiDataGrid` bug where the `setCellProps` callback passed by `renderCellValue` was not correctly applying custom `data-test-subj`s ([#8011](elastic/eui#8011)) **Accessibility** - Updated the `EuiBasicTable` actions button's `aria-label` by adding a reference to the current row ([#7994](elastic/eui#7994)) **CSS-in-JS conversions** - Converted `EuiDataGrid`'s toolbar controls to Emotion ([#7997](elastic/eui#7997)) - Removed `$euiDataGridPopoverMaxHeight` - Converted `EuiDataGrid` to Emotion ([#7998](elastic/eui#7998)) - Removed `$euiZDataGrid` - Removed `$euiZHeaderBelowDataGrid` - Converted `EuiDataGrid`'s `gridStyle`s to Emotion; Removed the following Sass variables and mixins: ([#8006](elastic/eui#8006)) - `$euiDataGridCellPaddingS` - `$euiDataGridCellPaddingM` - `$euiDataGridCellPaddingL` - `$euiDataGridVerticalBorder` - `$euiDataGridPrefix` - `$euiDataGridStyles` - `@euiDataGridSelector` - `@euiDataGridStyles` - Converted `EuiDataGrid`'s cell popover, actions, and focus outline to Emotion; Removed the following Sass variables and mixins: ([#8011](elastic/eui#8011)) - `$euiZDataGridCellPopover` - `@euiDataGridCellFocus` - Converted `EuiDataGrid`'s row, header, and footer cells to Emotion; Removed the following Sass variables and mixins: ([#8013](elastic/eui#8013)) - `$euiDataGridColumnResizerWidth` - `@euiDataGridRowCell` - `@euiDataGridHeaderCell` - `@euiDataGridFooterCell`

`v95.10.1`⏩`v95.11.0` > [!note] > The bulk of this release is **EuiDataGrid**. The component has been fully converted to Emotion, and several UX changes have been made to data cell actions. We recommend QA testing any data grid(s) that have custom styles applied to them. _[Questions? Please see our Kibana upgrade FAQ.](https://github.com/elastic/eui/blob/main/wiki/eui-team-processes/upgrading-kibana.md#faq-for-kibana-teams)_ --- ## [`v95.11.0`](https://github.com/elastic/eui/releases/v95.11.0) - Updated `EuiText`, `EuiTextColor`, and `EuiTextAlign` with a new `component` prop that allows changing the default rendered `<div>` wrapper to a `<span>` or `<p>` tag. ([elastic#7993](elastic/eui#7993)) - Updated `EuiDataGrid`'s cell actions to always consistently be left-aligned, regardless of text content alignment ([elastic#8011](elastic/eui#8011)) - Increased `EuiDataGrid`'s cell actions hover zone to reduce UX friction when mousing over from the grid cell to its actions ([elastic#8011](elastic/eui#8011)) **Bug fixes** - Fixed `EuiPopover` to correctly inherit from `EuiProvider`'s `componentDefaults.EuiPortal.insert` ([elastic#8003](elastic/eui#8003)) - Fixed push `EuiFlyoutResizable`s to not potentially block scrollbars on outside content ([elastic#8010](elastic/eui#8010)) - Fixed an `EuiDataGrid` bug where the `setCellProps` callback passed by `renderCellValue` was not correctly applying custom `data-test-subj`s ([elastic#8011](elastic/eui#8011)) **Accessibility** - Updated the `EuiBasicTable` actions button's `aria-label` by adding a reference to the current row ([elastic#7994](elastic/eui#7994)) **CSS-in-JS conversions** - Converted `EuiDataGrid`'s toolbar controls to Emotion ([elastic#7997](elastic/eui#7997)) - Removed `$euiDataGridPopoverMaxHeight` - Converted `EuiDataGrid` to Emotion ([elastic#7998](elastic/eui#7998)) - Removed `$euiZDataGrid` - Removed `$euiZHeaderBelowDataGrid` - Converted `EuiDataGrid`'s `gridStyle`s to Emotion; Removed the following Sass variables and mixins: ([elastic#8006](elastic/eui#8006)) - `$euiDataGridCellPaddingS` - `$euiDataGridCellPaddingM` - `$euiDataGridCellPaddingL` - `$euiDataGridVerticalBorder` - `$euiDataGridPrefix` - `$euiDataGridStyles` - `@euiDataGridSelector` - `@euiDataGridStyles` - Converted `EuiDataGrid`'s cell popover, actions, and focus outline to Emotion; Removed the following Sass variables and mixins: ([elastic#8011](elastic/eui#8011)) - `$euiZDataGridCellPopover` - `@euiDataGridCellFocus` - Converted `EuiDataGrid`'s row, header, and footer cells to Emotion; Removed the following Sass variables and mixins: ([elastic#8013](elastic/eui#8013)) - `$euiDataGridColumnResizerWidth` - `@euiDataGridRowCell` - `@euiDataGridHeaderCell` - `@euiDataGridFooterCell` (cherry picked from commit 9bbb296)

# Backport This will backport the following commits from `main` to `8.x`: - [Upgrade EUI to v95.11.0 (#192756)](#192756)  ### Questions ? Please refer to the [Backport tool documentation](https://github.com/sqren/backport)  --------- Co-authored-by: Cee Chen <[email protected]> Co-authored-by: Cee Chen <[email protected]>

thomasneirynck mentioned this pull request Aug 18, 2016

Kibana should bind to 0.0.0.0 in dev mode #8010

Closed

thomasneirynck force-pushed the enh/7196 branch from 33aa5d4 to d08ab99 Compare August 19, 2016 20:42

thomasneirynck added review v5.0.0-beta1 labels Aug 19, 2016

Bargs self-assigned this Aug 19, 2016

epixa added the release_note:breaking label Aug 19, 2016

jbudz self-assigned this Aug 22, 2016

jbudz reviewed Aug 23, 2016
View reviewed changes

Bargs reviewed Aug 23, 2016
View reviewed changes

thomasneirynck force-pushed the enh/7196 branch from 2acc9e4 to b0f93f0 Compare August 24, 2016 17:11

Bargs reviewed Aug 24, 2016
View reviewed changes

thomasneirynck force-pushed the enh/7196 branch from 942c37a to fd3d147 Compare August 24, 2016 20:17

thomasneirynck added 2 commits August 25, 2016 12:41

Bind Kibana server to localhost

549293d

This is a breaking change. The default behaviour will now be that connections from remote users will be rejected.

Improve doc

e702c6d

thomasneirynck force-pushed the enh/7196 branch from fd3d147 to e702c6d Compare August 25, 2016 16:42

thomasneirynck merged commit f49bf02 into elastic:master Aug 25, 2016

thomasneirynck deleted the enh/7196 branch August 26, 2016 21:09

ruflin added a commit to ruflin/beats that referenced this pull request Sep 8, 2016

Update to kibana to most recent snapshot

f91c1b5

* Timelion is now part of master, not need to install it anymore * Default host is now localhost, 0.0.0.0 for dev needs config file: elastic/kibana#8013

ruflin mentioned this pull request Sep 8, 2016

Update to kibana to most recent snapshot elastic/beats#2498

Merged

tylersmalley mentioned this pull request Sep 28, 2016

Allows for server.host to be set in development #8487

Merged

thomasneirynck mentioned this pull request Oct 13, 2016

Kibana to bind to localhost by default #7196

Closed

epixa added the v5.0.0 label Oct 23, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bind Kibana server to localhost #8013

Bind Kibana server to localhost #8013

thomasneirynck commented Aug 17, 2016 •

edited

Loading

thomasneirynck commented Aug 17, 2016 •

edited

Loading

jbudz Aug 23, 2016

jbudz commented Aug 23, 2016

thomasneirynck commented Aug 23, 2016

Bargs Aug 23, 2016

thomasneirynck Aug 24, 2016 •

edited

Loading

Bargs Aug 24, 2016

thomasneirynck Aug 24, 2016

Bargs Aug 24, 2016

thomasneirynck Aug 24, 2016 •

edited

Loading

Bargs Aug 24, 2016

Bargs Aug 24, 2016

Bargs commented Aug 24, 2016

thomasneirynck commented Aug 25, 2016

Bind Kibana server to localhost #8013

Bind Kibana server to localhost #8013

Conversation

thomasneirynck commented Aug 17, 2016 • edited Loading

thomasneirynck commented Aug 17, 2016 • edited Loading

jbudz Aug 23, 2016

Choose a reason for hiding this comment

jbudz commented Aug 23, 2016

thomasneirynck commented Aug 23, 2016

Bargs Aug 23, 2016

Choose a reason for hiding this comment

thomasneirynck Aug 24, 2016 • edited Loading

Choose a reason for hiding this comment

Bargs Aug 24, 2016

Choose a reason for hiding this comment

thomasneirynck Aug 24, 2016

Choose a reason for hiding this comment

Bargs Aug 24, 2016

Choose a reason for hiding this comment

thomasneirynck Aug 24, 2016 • edited Loading

Choose a reason for hiding this comment

Bargs Aug 24, 2016

Choose a reason for hiding this comment

Bargs Aug 24, 2016

Choose a reason for hiding this comment

Bargs commented Aug 24, 2016

thomasneirynck commented Aug 25, 2016

thomasneirynck commented Aug 17, 2016 •

edited

Loading

thomasneirynck commented Aug 17, 2016 •

edited

Loading

thomasneirynck Aug 24, 2016 •

edited

Loading

thomasneirynck Aug 24, 2016 •

edited

Loading